CBC Casper: Sharding
Philosophy
A sharded consensus protocol is a consensus protocol where nodes make different (but consistent) decisions, and where nodes don't have to receive and every message and/or completely execute the fork choice rule
Sharding is inside a consensus protocol design
Safety proof follows the CBC framework
Decisions made on any two shards are not necessarily independent, no matter where on the tree they are. (Ref) Atomic X-shard messaging system
by hierarchical fork-choice rule (chain validity rule)
Resources
The CBC Casper Approach to Sharding Slide Video @DEVCON5 by Aditya & Vlad Previous proposal: Merge block
Load balancing
Necessity to have a routing table to deliver a cross-shard message to the final destination under topology rebalancing
Infinite loop of the fork-choice due to topology rebalancing (Vlad found a fix "but didn’t finish fixing all the bugs before the demo")
nrryuya.icon > This is no longer a problem in the latest spec by the "source-source consistency" condition?
"A solution to avoid the problem of the root node having a huge dictionary of which account lives where, and every intermediate node below it also needing a full and exact set of all accounts on the nodes below it."
Notes
It's not synchronous calls, the concern about synchronous call is deadlock (Ref) Validators must hear from a shard, it's parent, it's parent, ... (Ref) We will assign different (mutually exclusive) subsets of the validator set to each shard. (Ref) Others